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Abstract. We propose method shells, which is a module system for 
avoiding conflicts on customization by language mechanisms such as as¬ 
pects in Aspect J and open classes in Ruby. These mechanisms allow pro¬ 
grammers to customize a library without rewriting original source code 
but by only describing differences in a separate file. We call these mech¬ 
anisms destructive class extensions. A problem with destructive class 
extensions is conflicts on customization. Different customizations may 
differently modify the same class. To address this problem, we propose 
a new module system named method shells. With this system, program¬ 
mers can avoid conflicts since the module system automatically switches 
a set of customizations that has to be applied together according to the 
contexts declared by programmers. We present the idea of this module 
system and then its formal semantics. We also present an extension of 
Java that supports method shells. 


1 Introduction 

Aspect-oriented programming (AOP) [1] is a programming paradigm where 
crosscutting concerns can be separated into different modules called aspects. 
Aspects can modify the behavior of the code contained in a different module so 
that they will implement their concerns. This mechanism, however, can be used 
for not only implementing a crosscutting concern but also customizing an exist¬ 
ing class library or framework to fit an application program. A class library (or 
framework) can be extended by subclassing but subclassing does not enable all 
kinds of customization. Some kinds of customization need to directly modify a 
class contained in the library. To modify such a class, aspects are useful language 
constructs from the viewpoint of software maintenance. 

Aspects are not only the mechanism for customizing a class library with¬ 
out directly changing the library source code. For this purpose, several other 
mechanisms have been proposed such as open classes in Ruby [2] and refines in 
AHEAD [3]. In this paper, we call this category of mechanisms destructive class 
extensions [4] since they directly modify the behavior of existing classes. 

A problem with destructive class extensions is that extensions often conflict 
with each other. This problem has been actively studied in the context of AOP 
but these studies have focused on conflicts observed when the implementations 
of different crosscutting concerns are woven at the same join point [5, 6]. On the 



other hand, in the context of library customization, an important issue is to 
deal with a library customized by destructive class extensions (or aspects) as 
a black box. This is non-trivial if two libraries require the same sub-library but 
differently customize it by destructive class extensions. An application program 
using the two libraries together will cause conflicts on the customization of the 
sub-library and thus the programmer has to be aware of the customization by 
the libraries; the libraries cannot be considered as black boxes. 

To avoid conflicts on the customization in this scenario, we propose a new 
module system named method shells and present an extension of Java that sup¬ 
ports this module system. 1 As a mechanism for destructive class extension, we 
use a reviser [4]. A method shell is a module that can contain classes and re¬ 
visers. It can include other method shells to extend and customize their classes. 
Furthermore, it can link to other method shells. The linked method shells are 
dealt with as black boxes. A method shell can invoke the code in the method 
shells linked to it but the invoked code is executed in a separate context so that 
it will not be affected by the customization effective in the method shell invoking 
the code. No unexpected conflicts happen between method shells linking to each 
other. 

In the rest of this paper, we first show a motivating example and then present 
method shells. We also present the formal semantics of the method shells and 
a brief sketch of their implementation. Finally, we mention related work and 
conclude this paper. 


2 Destructive class extensions 

When programmers need to customize a class library, the customization would 
be convenient if they can modify it without directly modifying the original source 
code by only describing differences in a separate hie. Such customization is mod¬ 
ular and easy to maintain. Even if the customization includes a bug, they can 
easily obtain the prior code by deleting the hie describing the customization. 

Although subclassing is often used to describe such customization, it does 
not perfectly ht the aim. Suppose that the library contains a class C and she 
wants to modify a method in that class. Describing a subclass of C that overrides 
the method is not sufficient to make a customized library. All the classes in the 
library that create an instance of C must be modified to create an instance of 
that subclass. Subclassing is, therefore, not the perfect approach for customizing 
an existing library in a modular fashion. 

For modular customization of existing libraries, several language mechanisms 
have been proposed in languages like Ruby [2], AspectJ [7], AHEAD [3], Mul- 
tiJava [8], Jiazzi [9], and GluonJ [4]. In this paper, we call these mechanisms 
destructive class extensions since they are mechanisms for directly modifying 

1 The first author submitted a summary of this work to ACM Student Research Com¬ 
petition (SRC) held in March at AOSD 2013. The submission will be reviewed and 
oral and poster presentations will be scheduled in March. Submitting a full paper to 
another conference is permitted by the SRC moderators. 



// in the browser library 
revise WebPage { 
void popup(HTML text) { 
warning("disabled"); 

} 

} 

Figure 1. A reviser for the WebPage 
class 


1 //in the HTML-renderer library 

2 class WebPage { 

3 void popup(HTML text) { 

4 // show a popup window. 

5 } 

6 void onClick(Mouse m) { 

7 URL url = m.getURLO; 

8 if (isPopupO) 

9 popup(url); 

10 ... 

11 } 

12 ... 

13 } 


Figure 2. WebPage class 


existing implementation. They allow programmers to append new methods to 
an existing class and substitute a new implementation of an existing method. 
The new implementation is described in a separate source hie and thus the orig¬ 
inal source hies are not modihed. Describing customization in a separate module 
is not sufficient for scalable modular customization. It also has to enable modu¬ 
lar reasoning; the customization must change the original implementation only 
through a public interface or well-designed extension points. Some languages 
such as AspectJ provide a powerful mechanism like pointcuts and thus their 
ability for modular reasoning is controversial [10,11]. Since they enable changes 
of any parts of module, preserving modularity in large scale software is not 
straightforward. On the other hand, in other languages like GluonJ, the cus¬ 
tomization changes the implementation by redehning public methods and hence 
they enable as modular reasoning as normal object-oriented programming. 

However, even in the latter languages, enabling modular customization is not 
easy. The customization through public methods will not scale as the number 
of methods increase. Different customizations may conflict on the same method. 
For better scalability, a scoping mechanism must be introduced so that the cus¬ 
tomization will be effective only within a limited space. This is the aim of this 
paper. 

Suppose that we have a library 1 1 for rendering an HTML text and we write 
another library l 2 for constructing a web browser that will be embedded in an 
application software. For code reuse, the library l 2 should be implemented on 
top of the former library l\. Since an embedded web browser should not show a 
popup window, which will surprise application users, we have to customize the 
library l\ so that a popup window will be blocked. 

A mechanism of destructive class extension allows this customization without 
modifying the source code of the library l\. Figure 1 shows the code for that 
modification. In this paper, we use the syntax of GluonJ [4]. The code modifies 
the original implementation of the WebPage class shown in Figure 2, which is 
contained in the library 1 It directly replaces the original implementation of 
the popup method with a new one in Figure 1. If the library l 2 contains the code 
in Figure 1, which is called a reviser , the behavior of the library l\ is revised 
and no popup window will not be displayed when l 2 uses l\. The original source 
code of popup does not have to be modified. 



We next write the third library 1%, which provides an audited viewer of local 
files written in HTML. The viewer shows a popup dialog for an alert when a 
confidential file is opened. To show a popup dialog, we use the popup method 
in the WebPage class supplied by the library l\ for rendering an HTML text. 
Furthermore, we modify several methods by revisers, for example, the getBorder 
method in the WebPage method so that the rendered HTML text will be shown 
in a specially decorated window. 

An application using either the library l 2 or I 3 will work well. However, since 
both I 2 and I 3 commonly use the library l\ but differently modify the classes in 
/-], an application using both of them will not work. The revisers in l 2 and I 3 
will conflict. For example, the reviser in l 2 disables to show a popup window by 
the popup method whereas the library I 3 needs that the popup method shows a 
popup window as its original implementation does. 

This conflict is a well-known problem with destructive class extensions [12, 
13,6] but it is more crucial than usual when destructive class extensions are 
used for customizing a library. A library is usually dealt with as a black-box; 
library users should be unaware of which other libraries are internally used by 
that library and how those other libraries are customized. It should be hidden 
that both the libraries l 2 and I 3 internally use l± and they differently customize 
l\. Thus, a conflict on 1 1 between l 2 and I 3 will be a surprise to their user 
programmers. This is a similar problem happening when an application requires 
two libraries and the two require other libraries that are different versions of 
the same library. A library providing basic functionality is often included by 
other third-party libraries but, if it is popular and being actively developed, 
these third-party libraries often require different versions of it. Such third-party 
libraries are difficult or impossible to use together. Our scenario of conflicts on 
customization can be regarded as a conflict between two versions of the library 
/-], each of that is implemented by revisers describing differences from the base 
version. 


3 Method Shells 


To address the problem presented in the previous section, we propose a new 
module system named method shells. With this module system, a set of revisers 
that must be applied together is implicitly switched to fit execution contexts 
during runtime. As a prototype of method shells, we have developed an extension 
of Java. In this extended Java, a new language construct called a method shell 
is available. It is a construct similar to package and it specifies a module that 
classes and revisers in the source file belong to. Figure 3 presents a Tenderer 
method-shell. The first line is a methodshell declaration, which declares that the 
following WebPage class is contained in the method shell named Tenderer. This 
method shell represents the HTML-renderer library 1 1 shown in the previous 
section. 



methodshell Tenderer; 

class WebPage { 
void popup(HTML text) { 
// show a popup window. 

} 

void onClick(Mouse m) { 
URL url = m.getURLO; 
if (isPopup()) 
popup(url); 

} ” 


1 methodshell browser; 

2 include renderer; 

3 

4 revise WebPage { 

5 void popup(HTML text) { 

6 warning("disabled") ; 

7 } 

8 } 

9 

10 public static void main(String[] args){ 

11 WebPage w = new WebPage(); 

12 w.popup("Available?"); // not shown 

13 } 


Figure 3. The Tenderer method shell 


Figure 4. The browser method-shell 


Include declarations and revisers 


In the previous section, the HTML-renderer library li was used by the web- 
browser library ? 2 - With the method shells, this relation is represented by an 
include declaration. Figure 4 presents a reviser in the browser library I 2 reimple¬ 
mented with method shells. The second line is an include declaration. It repre¬ 
sents that the browser method-shell includes the renderer method-shell. All the 
classes and revisers contained in the renderer method-shell are also contained in 
the browser method-shell. This relation by include declarations is transitive. 

The reviser in Figure 4 belongs to the browser method-shell and it modifies 
the implementation of the WebPage class. The WebPage class is called a target 
class and it must be in the same method shell that the reviser belongs to. Since 
include declarations constructs transitive relations, the WebPage class could be 
in a method shell included by the method shell that the reviser belongs to. 
A method shell is a scope of the visibility of classes and revisers. Classes and 
revisers can refer to only the class names contained in the same method shell. 

The implementations of the methods declared in a reviser substitute the 
original ones in the target class or they are appended to the target class if they 
are new methods. The reviser in Figure 4 substitutes the implementation of 
the popup method in the WebPage class. Although the source code of the orig¬ 
inal implementation is not modified, the modification by the reviser is directly 
applied to the target class. This is a difference from subclassing. The modifi¬ 
cation by a subclass of WebPage will not affect the instances of WebPage but 
the modification by a reviser for WebPage affects the instance of the target class 
WebPage. 

A method shell can contain a special function main. It is a main method where 
the whole program starts. In Figure 4, the main method makes an instance of 
WebPage and calls the popup method on it. Since this method shell contains a 
reviser for WebPage, the implementation of popup in the reviser is selected and 
executed. A popup window is not displayed. 

When the program starts from the main method in a method shell S, it 
runs with the modifications by the revisers contained in S unless the program 
contains link declarations mentioned later. For clarity, if a program is running 
with the modifications by a method shell S, we call S the current context. Note 



1 methodshell viewer; 

2 include Tenderer; 

3 

4 class Viewer { 

5 void check(File f) { 

6 if (isConfidential(f)) 

7 new WebPage().popup("<b>Confidential</b>"); 

8 } 

9 ... 

10 } 

11 revise WebPage { 

12 Border getBorder() { 

13 // return a decorated window border 

14 } 

15 } 


Figure 5. The viewer method shell 

that all revisers contained in the same method shell are applied together to 
classes in that method shell. If multiple revisers share the same target, they 
are applied in the precedence order given by the programmer. For backward 
compatibility, our extended Java language allows classes in a source file without 
a methodshell declaration. Such classes belong to a special method shell that are 
implicitly included by any method shell. We call this special method shell the 
global context. 

Link declarations 

In the previous section, the library li was also used by the audited-viewer li¬ 
brary I 3 . Figure 5 shows one of the source files of the library I 3 after being 
reimplemented with method shells. It contains a class and a reviser as well as 
the include declaration for including the Tenderer method-shell. This reimplemen¬ 
tation of I 3 will work correctly if it is used independently. However, if we define 
a new method shell that naively includes both I 2 and I 3 , the customizations of 
1 1 by the revisers in the two libraries I 2 and I 3 will conflict as we already saw in 
the previous section. 

To address this conflict, the method shells provide a link declaration so that 
programmers can deal with a method shell as a black box. Here, being a black 
box means that the mere users of a method shell are not aware of its internals: 
which sub method-shells are included and how they are customized. For the 
developers who customize a method shell, it is still a gray-box; its internals 
are partly visible and customizable through a public interface. In large-scale 
applications, we believe that this sense of being a black box and/or a gray box 
would be necessary. It would be error-prone to construct such a large application 
by combining only gray-box libraries while manually avoiding conflicts. 

The method shell linked by a link declaration is not included but the classes 
and the revisers in that method shell become visible. See Figure 6. This source 
file belongs to the application method-shell and it includes the browser method- 
shell by the include declaration. Since the third line is a link declaration, the 
application method-shell does not include the viewer method shell. However, the 
main method in the application method-shell can refer to the Viewer class, which 
belongs to the viewer method-shell. 



1 methodshell application; 

2 include browser; 

3 link viewer; 

4 

5 public static void main(String[] args) { 

6 new WebPage().popup(); 

7 new Viewer().check (new File("secret.txt"); 

8 } 


Figure 6. The application method-shell and the link declaration 



Figure 7. The method shell commonly shared 

A unique feature of link declarations is the current context during the exe¬ 
cution of the code in the linked method-shell. While a method implementation 
contained in the linked method-shell is executed, the current context is set to 
that linked method-shell. For example, when the main method in Figure 6 calls 
the check method, since the implementation of check is in the viewer method- 
shell, the current context is changed from the application method-shell to the 
viewer method-shell. During the execution of the check method, therefore, only 
the revisers in the viewer method-shell are effective. The revisers in the appli¬ 
cation method-shell are not effective. The reviser for the WebPage class in the 
browser method-shell, which is included by application, is not effective and thus 
the check method can execute the original implementation of the popup method. 
The current context is switched back to the application method-shell when the 
execution of the check method finishes. 

A link declaration allows a program to execute a method in a space separated 
from other modules’. In our example scenario, the original implementation of 
popup method is in the l\ library, or the renderer method-shell. It is included in 
the application method-shell through the library 12 and I 3 , or the browser method- 
shell and the viewer method-shell, respectively. The problem is that popup is 
modified differently by the paths through I 2 and Z 3 and our solution is to make 
two versions of popup for each path. One is for the path from application to 
I 2 and 1 1 while the other is for the path from I 3 to l\. The former version is 
modified by using the application method-shell as the current context while the 
latter is by using the viewer method-shell. The two versions are switched when a 
method implementation in the linked method shell is invoked. This problem and 
the solution are similar to the diamond inheritance problem [14] and its solution. 





4 Semantics and Implementation 


This section presents the formal semantics of method shells. It also presents 
the sketch of the implementation technique of method shells. This technique 
was used to develop a prototype compiler of our extended Java, which supports 
method shells. This compiler was developed by using the JastAclclJ framework 

[15]- 

4.1 Syntax 

We first present a simple calculus for the formalization. It is an extension of 
Featherweight Java (FJ) [16] and GluonFJ [4]. The syntax is given as follows: 


SL ::= methodshell S; IL LL (CL || RV) * MF 

method-shell declaration 

IL ::= include S; 

include declaration 

LL ::= link S; 

link declaration 

CL class C extends C{C f;K M} 

class declaration 

RV ::= revise C{M} 

reviser declaration 

M C m(C x){return e; } 

method declaration 

MF ::= void main(){return e; } 

main function declaration 

e ::= x | e.f | e.m(e) | new C(e) | e in S; Sc 

expressions 

v ::= new C(v) 

values 


The metavariables S and T range over method shell names; B, C, and D range 
over class names; f range over field names; m ranges over method names; x ranges 
over parameter names: K ranges over constructor declarations; v and w range 
over values. The syntax of K and body is not shown here but it conforms to FJ. 
In this syntax, we use an overline to represent a sequence. For example x equals 
to “x 1 ,x 2 , ...,x n ” and C f equals to “Ci fi,C 2 f 2 ,...,C n f n ”. 

SL is a method shell. It consists of its name, include declarations, link decla¬ 
rations, class declarations CLs and reviser declarations RVs, and a main-function 
declaration MF. A class declaration CL consists of its name, its super class, fields, 
a constructor, and methods. A reviser declaration RV consists of its name and 
methods. A reviser cannot have a field. An expression e may take a new form e 
in S; S c , which is used to mark which method shell e originates from and the 
current contexts in the operational semantics. 

We denote the class and reviser table by CRT. It is a mapping from a pair 
of a method shell S and a class name C to a class declaration CL or a reviser 
declaration RV. A program is a pair of CRT and a method-shell name. The 
program execution starts from the main function included in the method shell 
with that name. 


4.2 Lookup semantics 

The reduction relation is of the form S; S c F e —> e', reading “expression e 
reduces to expression e' in one step in a method shell S and the current context 
Sc- If a program starts from the main function in a method shell S, then the 





program execution is to reduce its expression e in the method shell S and the 
current context S. Most reduction rules are given in a straightforward manner 
from FJ’s and GluonFJ’s. Interesting rules are the followings: 


_ T;Tcl~eo- 

S;Scl~eo in T,Tc- 


>ep 

>eo' 


in T;Tc 


(R-In) 


mbody(m,C,S,Sc)= x.eo in T;Tc 
S;S c hnew C(v).m(w)->-([w/x,new C(v)/this]eo) in T;T C 


(R-Invk) 


The first rule is straightforward, eg is reduced in T; Tc although S; Sc are given. 
The second rule is for method invocation. Unlike FJ’s, a function to look up a 
method body, named mbody , takes four parameters. It looks up a method body 
by referring to the method name m, the class of the target object C, the method 
shell S that the expression originates from, and the current context Sc- Both S 
and Sc are ones at the caller-side. If a method body e with parameters x is found 
in a method shell T and the new current context is set to Tc, then the method 
body is executed with the arguments w in T and Tc. 

The definition of mbody is presented in Figure 8. mbody{ m,C,S,Sc) returns 
the body of m called on the C class from the method shell S with the current 
context Sc, written x.e in T; Tc, where x are parameters, e is the method body, 
T stands for the method shell where the body is found, and Tc stands for the 
current context used to execute the body. 

mbody uses a few auxiliary functions, including s(S) returns a set of method 
shells directly included by S. linked-shells( S) returns a set of method shells 
linked by S. mbodyshell{ m,C,S) is a function to search the method shell S. 
It returns the body of method m in class C found in S. It first searches the 
method bodies directly contained in S and then recursively searches ones in 
method shells included by S. Finally, mbody global ( m, C, S, Sc) searches the global 
context, which contains classes in source files without methodshell declarations. 
The global context is a special method shell implicitly included by any method 
shell. In Figure 8, Global stands for the global context. Note that, if the body 
of m in the class C is not found in the global context, mbodyglobal searches the 
method bodies declared in a super class of C by recursively calling mbody. 

mbody( m, C, S, Sc) searches in the following order. First, it searches the method 
shells linked by S. If a method body m is found, the new current context is set to 
the linked method shell where the body is found. Otherwise, mbody searches the 
current context Sc- Note that it does not search the method shell S, which the 
method-call expression originates from. S is used only for obtaining the linked 
method shells searched at the first step. If a method body is not found in either 
the linked method shells or the current context, then mbody searches the global 
context. Finally, if a method body directly declared in the class C is not found 
in any method shells, mbody looks up a method body declared in a super class 
of C. The current context does not change except the first step. 


4.3 Implementation 

Our prototype compiler transforms a program using method shells into plain 
Java program, which is then compiled into Java bytecode. During the trans- 



Methodbody lookup 

mbody (m,C,S,Sc)=x.e in T;Tc 

CRT(S,C) = (revise C{M})11(class C---{---M}) 

B m(B x){return e;}£M 
mbody shell (m,C,S)=x.e in S 

T c =linked- shell s(S) 


3T C i£T c mbody shell(m,C,T c ±)=x.e in T 

CRT(S,C) = (revise C{M}) 11 (class C...{ --M}) 

VT C j £T C mbodyshell(m,C,T c j)=mill 

m is not defined in M 

mbody( m,C,S,S c )=x.e in T;T c j 

S=includings(S) 

3Si£S mbodyshell( m,C,Si)=x.e in T 

VSj GS(i^j) mbody shell (m,C,Sj )=null 

T c =linked- shell s(S) 

mbody shell (m,C,S)=x.e in T 

VT c i£T c mbodyshell (m,C,T C i)=null 

mbody shell( m,C,S c )=x.e in T 


mbody( m,C,S,S c )=x.e in T;S C 

CRT(S,C) = (revise C{M>)11(class 
m is not defined in M 

including s (S)=null 

T c i=linked-shells(S ) 

mbody shell(m,C,S)=nvLll 

VT C iGT c mbody shell{ m,C,T C i)=null 
mbody shell( m,C,S c )=null 


mbody (m, C, S, S c )=mbody global (m,C,S,S c ) 

CRT(Global,C)=class C extends D{C f;K M} 

B m(B x){return e;}£M 


mbody global^ m,C,S,S c )=x.e in null;null 

mbody (m,C, null, null) =mbody global (m,C, null, null) 



CRT(Global,C)=class C extends D{C f;K M} 

m is not defined in M 

mbody global (m,C,S,S c )=mbody(m,D,S,S c ) 


Figure 8. A function to look up a method body 


formation, the methods in revisers are copied into the declaration of the target 
class. If the method already exists in the target class, the method copied from the 
reviser substitutes the original one. Our prototype compiler/language has not 
supported a mechanism to invoke the overridden implementation of a method 
by a call on super. 

However, if multiple revisers in different method shells modify the same 
method, the naive approach above will not work. Our compiler hence copies 
a method implementation after renaming the method into the name mangled 
from the original method name and the method-shell name. A method m de¬ 
clared in a reviser for a class C is copied into the declaration of C after the 
method name is changed into the name ms mangled from the method name m 
and the method shell S, which the reviser is contained in. 

When a method m is called on an instance of a class C, the appropriate 
implementation is selected among the available versions rngi, m$ 2 , m$ 3 ,... for each 
method shell Si. According to the semantics we showed above, the selection 
depends on the method shell that the method-call expression originates from 
and the current context. The former one is statically determined but the latter 
one is not. Thus, a naive implementation will have to check the latter one at 
runtime for method dispatch. This will cause a runtime penalty. 




To minimize runtime penalties due to method shells, our prototype compiler 
duplicates a method implementation for different current contexts and trans¬ 
forms the method body to customize. Therefore, a method mg; is duplicated into 
msi-Ti) rnsi.T 2 i rnsi-T 3 , • where Tj is a current context. The body of the method 
msi-Tj is transformed for S; and Tj. The transformation for a method shell S and 
a current context Sc under type environment r is written S; Sc b e =>■ e'. 
For most expressions, the transformation is trivial. Only method calls must be 
changed: 

S;Sc;/ n Heo=^-eo / S;Sc;.^'l-e=>e , S;Sc;i~'l-eo:C mname( m,C,S,Sc)=m / 

S;Sc;i^l - eo.m(e)=>eo / .m^e') 

Here, S; S c ;T b e 0 : C is read “expression eg is given type C under type environ¬ 
ment r.” In other words, the static type of eo is C. mname is a function to look 
up a method like mbody. It is defined as following: 

mbody( m,C,S,Sc)=x.e in null;null 
rrmarae (m, C, S, Sc) =m 

mbody( m,C,S,Sc)=x.e in T;Tc 
mname (m,C,S, Sc )=iiit.t c 

If the method implementation is selected from the global context, the method 
name is not changed during transformation. 

Finally, the body of the main function is transformed so that the appropriate 
version of methods will be called. If the program starts with the main function 
in a method shell S, then the body is transformed for S and S. 

5 Related Work 

In the context of AOP, a number of researchers have been studying conflicts 
of advices, or aspect interference. Aksit et al. proposed a mechanism for de¬ 
tecting aspect interference by using graph transformation [6]. Several linguistic 
constructs have been proposed to resolve the interference. Douence et al. pro¬ 
posed a new composition operator of aspects [12,13]. It allows programmers to 
describe a safely-composable aspect. Airia provided a new kind of around advise 
called resolvers for resolving the interference [17]. A uniqueness of our work is 
that we have designed a language construct specialized for a specific use-case 
scenario where aspects are used for building a custom library to be used as a 
black box. 

AOP and destructive class extensions can be regarded as a special case of 
virtual classes [18,19], where all base-level classes are implicitly contained as 
virtual classes in a single enclosing class and all aspects (or corresponding con¬ 
structs like revisers) are in a subclass of that enclosing class, if the differences 
in how to specify the target base-level classes are ignored (the targets in AOP 
are specified by pointcuts while ones in virtual classes are by the super-class 
names). Our method shells are an approach to introduce a scope mechanism 
into destructive class extensions. In the analogy above, this approach allows 
programmers to use more than one enclosing classes in programming with de¬ 
structive class extensions ( i.e. AOP) as they can do in programming with virtual 



classes. Therefore, the resulting language mechanism is similar to ones for virtual 
classes but it still has some unique features since it is originated from destructive 
class extensions. For example, in method shells, programmers are less aware of 
the existence of enclosing classes. When a program refers to a class contained in 
a different enclosing class, it does not have to explicitly specify the name of that 
different enclosing class. That class is implicitly selected by the link declaration 
so that the obliviousness property [20] is somewhat preserved. Another example 
is that, in method shells, the method selected for a method call on the same 
target object changes depending on the caller’s contexts. Furthermore, method 
shells allow multiple shells to be included at the same time like mixing. 

In Newspeak [21], all class names are virtual and a subclass can override them. 
This overriding mechanism corresponds to the include declaration in method 
shells. On the other hand, Newspeak does not provide a mechanism correspond¬ 
ing to the link declaration, with which the method-lookup context is changed 
after a method in the linked method-shell is selected. Although Newspeak is dy¬ 
namically typed, method shells are statically typed and we present a technique 
for reducing their method-lookup overhead. 

The idea of method lookup depending on runtime contexts is found not 
only in our method shells but also other languages such as JPred [22]. JPred 
supports predicate dispatch, with which a method is selected by referring to 
calling contexts such as method arguments and caller objects. 

Us [23] allows programmers subjectivity-based programming. In Us, every 
method call explicitly takes a method-lookup context called a perspective. In 
method shells, every call does not take such a context, which is declared by a 
include or link declaration at the beginning of the source file. 

Context-oriented programming (COP) [24] is a paradigm where a class defi¬ 
nition can be changed depending on the contexts during runtime. A class decla¬ 
ration is divided into multiple parts, which are called layers, and different layers 
may contain different implementations of the same method. Layers are dynami¬ 
cally switched by with and without clauses. Within the with clause, the specified 
layer is effective while in the without clause it is ineffective. A layer provides the 
same ability for destructive class extension as our revisers but a layer must be 
contained in the declaration of the target class although a reviser is described 
separately from the target class. Despite this difference, method shells and COP 
share the idea of changing class definition to fit the current context. 

However, the with and without clauses are not adequate for addressing the 
problem mentioned in this paper. Programmers in COP languages cannot deal 
with a layer as a black box. They have to understand the dependency among 
all layers and classes used in their programs. Figure 9 shows a program that 
is equivalent to the program in Figure 6 but is written in ContextJ, a COP 
extension of Java [25]. This program starts from the main method in the App 
class. Since it uses the renderer, the browser, and the viewer, it first activates all 
the three by with (line 10 to 12). However, while the check method in Viewer is 
executed, the browser layer must be deactivated since it needs a popup window. 
In Figure 9, the browser layer is deactivated within the body of the check method 



class WebPage{ 
layer(renderer){ 
void popup(HTML text){ 

// show a popup window 

} 

void onClick(Mouse m){ 

URL url = m.getURL(); 
if (isPopup()) popup(url); 

} 

} 

} 

layer(browser){ 
void popup(HTML text){ 
warning("disabled"); 

} 

} 

} 

class Viewer{ 
layer(viewer){ 
void check(File f){ 

if (isCirfidential(f) ) { 
without(browser){ 
new WebPage.popup 

("<b>Confidencial</b>"); 


1 class App{ 

2 void run(){ 

3 new WebPage().popup(); 

4 //a popup is disabled 

5 new Viewer().check 

6 (new File("secret.txt"); 

7 //a popup is needed 

8 } 

9 public void main(String[] args){ 

10 with(Tenderer){ 

11 with(browser){ 

12 with(viewer){ 

13 new App.run(); 

14 } 

15 } 

16 } 

17 } 

18 } 



Figure 9. A program in ContextJ 

by without (line 23) but this requires the programmer of Viewer to be aware of the 
browser layer, which might be independently developed from the Viewer. Another 
approach is to deactivate the browser layer within the body of the run method 
in App, for example, just before calling the check method at line 5. However, 
this requires the programmer of App to be aware that the browser layer must 
be deactivated while a Viewer is running. The programmer cannot deal with 
Viewer as a black box. A recent version of Context J supports Reflection API [26] 
and hence the problem above is fairly overcome. In this language, a program 
can obtain all the layers currently activated and then deactivate them. However, 
unlike method shells, the programmer still has to be aware of unnecessary layers 
and explicitly deactivate them. 

Classboxes [27, 28] are a module system that also provides a scoping mecha¬ 
nism for destructive class extensions. In Classbox/J, related classes are modular¬ 
ized into a module called a classbox. It can include other classboxes and partly 
modify them by refine, which corresponds to a reviser in our language. However, 
Classboxes do not provide a mechanism corresponding to our link declarations 
and thus they cannot handle the scenario shown in this paper. If the library 
1 1 is included through multiple paths, all the refines on the paths are applied 
together. 

In Java, every class loader has its own name space. Hence, distinct imple¬ 
mentations of the same class can coexist in one program if they are loaded into 
different class loaders. This is useful to partly address the problem discussed 
in this paper but moving an object beyond the boundary between class loaders 
is significantly restricted. In method shells, such restriction known as the ver- 



sion barrier is not applied. To enable such movement between class loaders, the 
Java virtual machine has to be modified and support a mechanism like sister 
namespaces [29]. 

We have already proposed method shelters, which is a mechanism similar 
to method shells [30]. Although the two mechanisms share the same approach, 
method shelters are for a dynamically typed language Ruby. The destructive 
class extension in Ruby is performed by open classes, which is different from 
revisers we used in this paper. Furthermore, the design of method shelters is 
more complicated than that of method shells. A method shelter, which is a unit 
of module, is divided into an exposed chamber and a hidden chamber. Pro¬ 
grammers have to carefully choose which chamber a reviser should be placed to 
control its visibility. On the other hand, a method shell is simpler but equiva¬ 
lently expressive; it is not divided into smaller containers but a single container. 
Programmers can intuitively control the visibility of revisers by choosing either 
an include declaration or a link declaration. 

6 Conclusion 

We proposed method shells, which are a module system for avoiding conflicts 
on destructive class extensions. The destructive class extensions are mechanisms 
for modifying class definitions from a separate module, which include aspects 
in AspectJ, open classes in Ruby, and revisers in GluonJ. A method shell is a 
module consisting of classes and revisers. It can include other method shells and 
the revisers in the included method shells are applied together as well as the 
revisers in the method shells including them. A unique feature is that a method 
shell can link to other method shells. The code included in the linked method 
shells can be invoked but it is executed in a context where only the revisers in 
the linked method shell are effective. Thus, a linked method shell is dealt with 
as a black box. 

Our contribution is to propose a mechanism for avoiding conflicts on destruc¬ 
tive class extensions when we use the extensions for customizing a class library 
or a framework. The resulting library or framework after customization can be 
dealt with a black box. The main idea is link declarations. The language auto¬ 
matically switches effective revisers when the thread of control crosses over to a 
linked method shell. Showing the formal semantics and implementation strategy 
of method shells is also contribution. 
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